Communication systems typically include a plurality of communication units, such as mobile or portable radio units and dispatch consoles that are geographically distributed among various repeater sites and console sites. The communication units wirelessly communicate with the repeater sites and each other, and are often logically divided into various subgroups or talkgroups. Communication systems may be organized as trunked systems, where a plurality of communication resources is allocated amongst multiple users or groups by assigning the repeaters within a radio frequency (RF) coverage area on a call-by-call basis, or as conventional (non-trunked) radio systems where communication resources are dedicated to one or more users or groups. In trunked systems, or in mixed trunked and conventional systems, there is usually provided a central controller/server (sometimes called a “zone controller”) for allocating communication resources among multiple sites. The central controller may reside within a single device or multiple devices and may be located at a fixed equipment site or may be distributed among the repeater or console sites.
In recent years, communication systems have begun to use Internet Protocol (IP) to transport packet data between endpoints (or “hosts” in IP terminology). The data is divided into IP packets called datagrams, which include addressing information (e.g., source and destination addresses) that enables various routers forming an IP network to route the packets to the specified destination(s). The destination addresses may identify a particular host or may comprise an IP Multicast address shared by a group of hosts. Examples of communication systems using multicast addressing are described and claimed in U.S. Pat. No. 6,141,347, titled “Wireless Communication System Incorporating Multicast Addressing and Method For Use” and U.S. Pat. No. 6,647,020 titled “Methods for Implementing a Talkgroup Call in a Multicast IP Network,” each of which is assigned to the assignee of the present invention and incorporated herein by reference in its entirety.
Oftentimes, multiple endpoints or hosts are attached on a local area network (LAN). For example, in a wide area trunking system that performs group call, there are typically two or more consoles attached on a LAN. It would be desirable for all participating endpoints on the LAN to reliably receive IP multicast packets that are routed to the LAN such as, for example, control messages from a zone controller for setting up a group call. Although known Automatic Repeat Request (ARQ) protocols may be employed to achieve reliable message transfer sessions between a sender and receiver (whereby the receiver may request the retransmission of data blocks that are either not received or received corrupted from the sender), the establishing of multiple ARQ sessions with multiple endpoints attached to a LAN is unwieldy and may impede system performance. Accordingly, to the extent that ARQ sessions may be used to establish reliable message transmissions between a server (e.g., zone controller) and multiple hosts (e.g., consoles) attached to a LAN, it would be desirable that ARQ sessions be established with less than all of the host devices (hereinafter termed “link Op(s)”) attached to the LAN at a particular site. Generally, such a scheme ensures that IP multicast message(s) addressed from the server to an IP multicast destination address have reliably reached the link Op(s) and in most instances may be received by other host devices (hereinafter termed “listening Op(s)”) attached to the LAN that have joined the multicast group address.
However, it is possible that packets may be dropped on the LAN such that, for example, a packet (e.g., packet #2) from the server reaches the link Op but is not received by a listening Op. This can cause the listening Op to “hang” indefinitely, discarding message #3, #4 and so forth as it awaits retransmission of packet #2, but such retransmission never occurs because the link Op, having successfully received packet #2 will not request retransmission of packet #2. It would be desirable for listening Ops to recover from incidents of lost packets without “hanging.”
Accordingly, there is a need for a method for reliably sending IP multicast packets to multiple host devices attached to a LAN. Advantageously, the method allows for designating one or more of the hosts as link Ops and establishing a reliable message exchange session between a server (e.g., zone controller) and the link Op so as to ensure that IP multicast messages have reliably reached the LAN. In most instances, the messages will be received by all participating hosts on the LAN that have joined the appropriate multicast group address. However, in the event that packets are dropped on the LAN and thereby not received by certain host devices, there is a need for the affected hosts to reliably receive the lost packets. Further, there is a need that the affected hosts accommodate and recover from incidents of lost packets without “hanging” and, most preferably, without requiring retransmission of the lost packets from the server. The present invention is directed to satisfying these needs.